home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / amok_lha / amok03.lha / IFFLoad_1.1 / IFFLoad.doc < prev    next >
Encoding:
Text File  |  1993-08-16  |  14.5 KB  |  332 lines
  1. (*---------------------------------------------------------------------------
  2.     :Program.    IFFLoad.mod
  3.     :Author.     Fridtjof Siebert
  4.     :Address.    Nobileweg 67, D-7-Stgt-40
  5.     :Phone.      0711/822509
  6.     :Shortcut.   [fbs]
  7.     :Version.    1.1
  8.     :Date.       24-May-88, 02:34:40 (!)
  9.     :Copyright.  PD or Shareware, anyway you like (I like Shareware better).
  10.     :Language.   Modula-II
  11.     :Translator. M2Amiga
  12.     :Imports.    none.
  13.     :UpDate.     07-Jun-88: Laden 3x schneller durch Assembler !!! [fbs].
  14.     :Contents.   Schnelle Ladeprozedur für IFF (ILBM)-Bilder.
  15.     :Remark.     Thanks to Pit and Frank for their ideas to load to BitMap
  16.     :Remark.     and to open a Window.
  17. ---------------------------------------------------------------------------*)
  18.  
  19. =============================================================================
  20.                       =   =   =   IFFLoad   =   =   =
  21.  
  22.                            © Copyright  1988 by
  23.                              Fridtjof Siebert
  24.                                Nobileweg 67
  25.                        7000 Stuttgart 40 (Stammheim)
  26.                             Tel: (0)711/822509
  27. =============================================================================
  28.  
  29.  
  30. Mit der von IFFLoad exportierten Procedure können IFF-Bilder geladen
  31. werden. Dabei wird das geladene Bild als Screen geöffnet. Das Bild kann
  32. optional im Hintergrund geladen werden, d.h. der Screen wird beim Öffnen
  33. nicht nach vorne, sondern nach hinten gelegt. Das Display (die
  34. Bildschirm-DMAs) können während dem Laden abgeschaltetet werden. Das erhöht
  35. die Geschwindigkeit. Gepackte Bilder werden entpackt. Beim Laden von
  36. HAM-Bildern wird das ham-Bit in den ViewModes gesetzt.
  37.  
  38. ------  Laden von IFF-Bildern:  ------
  39.  
  40. Das Programm ShowIFF lädt und zeigt ein IFF-Bild. Es lädt das vorher auf
  41. der Workbench angeklickte oder, beim starten vom CLI, das hinter dem Namen
  42. angegebene Bild. Bilder, die ShowIFF als Default-Tool haben (Info), können
  43. durch einfachen Doppelklick angezeigt werden. An diesem kurzen Programm
  44. kann man leicht die Verwendung der Ladeprozedur studieren.
  45.  
  46. ------  Informationen zum Bild:  ------
  47.  
  48. Man braucht, um IFF-Bilder zu laden, eigentlich keine Ahnung von
  49. IFF-Dateien haben. Wer jedoch Interesse an den genauen geladenen Werten
  50. hat, der kann die Variable IFFInfo importieren. Sie enthält ein großes
  51. verschachtelte RECORD. Vorsicht beim Laden von mehreren Bildern !!!
  52. IFFInfo wird bei jedem Laden überschrieben. Man sollte dann den Typ
  53. IFFInfoType importieren und IFFInfo in eigene Variablen kopieren.
  54.  
  55. ------  Laden in BitMap:  ------
  56.  
  57. Es ist möglich, beim Laden keinen Screen zu öffnen. Dies geschieht beim
  58. Aufruf von ReadILBM durch die Option `dontopen'. Es wird eine BitMap-
  59. Struktur angelegt, die die Bilddaten enthält. Sie befindent sich in
  60. NuScreen.customBitMap^ (NuScreen importiert). Der Screen kann nachträglich
  61. mit OpenScreen(NuScreen) geöffnet werden. Danach muß man jedoch die
  62. Farben (sie stehen in IFFInfo.CMAP) mit SetRGB4() setzen. Vorsicht !!! Bei
  63. `dontopen' muß der Speicher für die Grafikdaten und die BitMapstruktur
  64. zurückgegeben werden! Eine BitMap ist normalerweise so groß wie die vom
  65. IFF-File angegebene Screengröße. Ist dies jedoch kleiner, oder nur die
  66. Breite oder nur die Höhe kleiner als die des Bildes selbst, so wird die
  67. BitMap auch entsprechend größer. Dies gilt auch für einen Screen, wenn
  68. dontopen nicht gesetzt ist !
  69. Ein Beispielprogramm dafür ist IFFBitMapDemo.
  70.  
  71. ------  ColorCycling:  ------
  72.  
  73. Von IFFLoad können auch noch die Prozeduren DoCycle() und EndCycle()
  74. importiert werden. Durch Sie kann man Colorcycling ein- bzw. ausschalten.
  75. Es wird ein Interrupt so initialisiert, daß er daß Cycling vollständig
  76. übernimmt. Wie man die Prozeduren handhabt kann man dem Programm
  77. ShowCycle.mod entnehmen. Es entspricht dem Programm ShowIFF, nur für
  78. Cycling-Bilder. Leider ist nicht bei allen nicht-Cycling Bilder das Color-
  79. Cycling korrekt ausgeschaltet, so daß man diese nicht mit ShowCycle zeigen
  80. kann (kein Guru, aber die Farben wandern !!!).
  81.  
  82. ------  DiaShow:  ------
  83.  
  84. Das Programm DiaShow zeigt mehrere Bilder nacheinander an. Alle Bilder, die
  85. gezeigt werden sollen, müssen vorher mit gedrückter SHIFT-Taste ausgewählt
  86. werden. Danach kann man DiaShow mit Doppelklick starten (SHIFT nicht
  87. vergessen). Die Bilder werden nacheinander ein- und ausgeblendet. Der
  88. Zeitabstand zwischen 2 Bildern beträgt 20 Sekunden. Vorher kann man mit der
  89. rechten Maustaste das nächste Bild ansehen, wenn dieses bereits geladen
  90. ist.
  91.  
  92. Wenn man DiaShow vom CLI aus startet, kann man die Bilder auch
  93. unterschiedlich lang zeigen lassen. Die Anzeigadauer gibt man jeweils nach
  94. dem Bildnamen an. Sie gilt auch für die dahinter folgenden Bilder.
  95.  
  96. Beispiel: DiaShow Bild1 10 Bild2 30 Bild3 Bild4 20
  97.  
  98. Bild1 wird 10, Bild2 und Bild3 30 und Bild4 20 Sekunden lang gezeigt.
  99.  
  100. ------  Importieren von IFFLoad:  ------
  101.  
  102. Wer von IFFLoad Prozeduren importiert braucht dazu die Datei IFFLoad.sym.
  103. Außerdem müssen beim Linken die Dateien IFFLoad.obj und LoadBody.obj
  104. vorhanden sein. Letztere enthält die Maschinenroutine zum schnellen Laden
  105. des BODYs.
  106.  
  107. ------  Die verschiedenen Dateien:  ------
  108.  
  109. IFFLoad.doc      : Diese Datei.
  110. ShowIFF          : ILBM-Ladeprogramm.
  111. ShowIFF.mod      : sein Quelltext.
  112. ShowCycling      : ILBM-Lader für Colorcycling-Bilder.
  113. ShowCycling.mod  : Quellcode.
  114. IFFBitMapDemo    : Demonstration für Laden mit Option `dontopen'.
  115. IFFBitMapDemo.mod: Source.
  116. DiaShow          : Lader für mehrere Bilder. Enthält Prozeduren zum Ein- und
  117.                    Ausblenden von Screens.
  118. DiaShow.mod      : Sourcecode.
  119. IFFLoad.def      : Definition der Ladeprozedur.
  120. IFFLoad.mod      : Ihre Implementation.
  121. IFFLoad.sym      : Symbol-Dation.
  122. IFFLoad.obj      : Fertig compiliertes IFFLoad.
  123. LoadBody.asm     : Der Assembler-Quelltext der Maschinenroutine.
  124. LoadBody.prg     : Die PC-relativ assemblierte Maschinenroutine.
  125. LoadBody.code    : File, das mit EXECUTE aufgerufen wird, und aus
  126.                    LoadBody.prg die Dateien -.def und -.mod erzeugt. Dazu
  127.                    muß sich das Tool M2ACode in einem mit Path angegebenem
  128.                    Directory befinden.
  129. LoadBody.def     : Die Definition von LoadBody.
  130. LoadBody.mod     : Die Implementation.
  131. LoadBody.sym     : Symbol-Datei.
  132. LoadBody.obj     : Und compiliert.
  133.  
  134.  
  135. ------  Copyright:  ------
  136.  
  137. Das Modul kann von jedem in nicht kommerziellen Programmen frei verwendet
  138. werden. Wer genügend Geld hat, der kann einem armen Schüler (mir !) auch
  139. eine Sharewaregebühr zukommen lassen. Mein ewiger Dank ist Ihm/Ihr dann
  140. gewiß !
  141.  
  142. Bevor ein Programm, das dieses Modul benutzt kommerziell genutzt wird
  143. (Veröffentlicht wird), muß sich der Autor mit mir in Verbindung setzten und
  144. eine eventuelle Vergütung aushandeln.
  145.  
  146. -----------------------------------------------------------------------------
  147.  
  148. ------  IFF für jedermann und jedefrau:  ------
  149.  
  150. Da das IFF-Format fast nirgends gut erklärt wird, möchte ich
  151. versuchen, wenigsten zum Bildformat eine einigermaßen brauchbare
  152. Beschreibung zu geben.
  153.  
  154. ------  Das IFF-Bildformat:  ------
  155.  
  156.   allgemeines:
  157.     Eine IFF-Datei beginnt mit der Kennung "FORM". Darauf folgt die
  158.     Länge der des Datenblocks.
  159.     Der Datenblock enthält dann die Kennung der Daten. Bei Bildern ist
  160.     sie "ILBM".
  161.     Darauf folgen beliebig viele Unterdatenblöcke. Sie beginnen
  162.     jeweils mit 4 Bytes, die die Daten Kennzeichnen. Ihnen folgt ein
  163.     Langwort, das wieder die Länge des Datenblocks angibt.
  164.  
  165.   Der Aufbau einer ILBM-Datei (vor dem Doppelpunkt jeweils die Nummer
  166.   des Bytes):
  167.  
  168.     0  :  "FORM"       -->  Kennzeichnet IFF-Datei.
  169.     4  :  LONGCARD     -->  Länge des Datenblocks, entspricht
  170.             Filelänge-8, da Daten beim 8. Byte beginnen.
  171.     8  :  "ILBM"       -->  Kennzeichnet Grafikdatei. (interleaved Bitmap)
  172.     12 :  Unterblock 1 -->  Die verschiedenen Daten.
  173.     x  :  Unterblock 2
  174.     y  :  etc.
  175.  
  176.   Die Unterblöcke:
  177.  
  178.     "BMHD", BitMapHeader:
  179.  
  180.        0  : "BMHD"       --> Kennung des Blocks.
  181.        4  : LONGCARD(20) --> Länge der Daten: 20 Bytes.
  182.        8  : CARDINAL(dx) --> Breite der Grafik.               (*)
  183.        10 : CARDINAL(dy) --> Höhe der Grafik.                 (*)
  184.        12 : INTEGER(x)   --> x-Position der Grafik (LeftEdge)
  185.        14 : INTEGER(y)   --> y-Position der Grafik (TopEdge)
  186.        16 : UBYTE(Depth) --> Anzahl der Bitplanes             (*)
  187.        17 : UBYTE(Masking) --> Maske für Grafik. Normalerweise keine (0).
  188.               1: Maske vorhanden , dann enthält "BODY" eine zusätz-
  189.                  liche Bitplane mit der Maske. Diese muß dann auch geladen
  190.                  werden.                                       (*)
  191.               2: Durchsichtige Farbe , dann steht in TransparentColor
  192.                  eine Farbnummer, die als durchsichtig gelten soll.
  193.               3: Eine Maske kann erzeugt werden, indem man eine Art Lasso um
  194.                  das Image wirft. Dazu zieht man eine Linie außen um das
  195.                  Image und füllt den Innenraum von diesem Rand mit
  196.                  transparentColor aus. Alles, was danach die Farbe
  197.                  transparentColor hat, ist durchsichtig.
  198.        18 : UBYTE(Compression) --> 0: Daten nicht gepackt     (*)
  199.                                    1: Daten gapackt, siehe "BODY"
  200.        19:  UBYTE(0)     --> nicht benutzt, muß 0 sein.
  201.        20:  CARDINAL(transparentColor) --> Durchsichtiga Farbe, siehe
  202.               Making.
  203.        22:  UBYTE(xAspect), UBYTE(yAspect) --> Verzerrung des Bildes.
  204.                          bei 320x200 normalerweise 10:11.
  205.        24:  INTEGER(dx)  --> Breite des Screens.
  206.        26:  INTEGER(dy)  --> Höhe des Screens.
  207.  
  208.        mit (*) gekennzeichnete müssen berücksichtigt werden.
  209.  
  210.     "CMAP", ColorMap:
  211.  
  212.        0  : "CMAP"       --> Kennung des Blocks.
  213.        4  : LONGCARD(x)  --> Länge des Blocks, entspricht der Zahl der
  214.               Farben durch drei. Gewöhnlich ist die Anzahl der Farben
  215.               gerade, weshalb kein Füllbyte eingefügt werden muß.
  216.        8  : UBYTE(Red)   --> Rotanteil Farbe 0
  217.        9  : UBYTE(Green) --> Grünanteil
  218.        10 : UBYTE(Blue)  --> Blauanteil
  219.        11 : UBYTE(Red)   --> Rotanteil Farbe 1
  220.        12 : etc.
  221.        x+7: UByte(Blue)  --> Blauanteil Farbe (x DIV 3)
  222.  
  223.     "GRAB" definiert einen besonderen Punkt (hot spot) in der Grafik.
  224.  
  225.        0  : "GRAB"       --> Kennung.
  226.        4  : LONGCARD(4)  --> Länge 4 Bytes.
  227.        8  : INTEGER(x)   --> x-Position des markierten Punktes
  228.        10 : INTEGER(y)   --> y-Position
  229.  
  230.     "DEST", destination:
  231.        gibt an, in welche Bitplanes die GrafikDaten geschrieben werden.
  232.  
  233.        0  : "DEST"       --> Kennung.
  234.        4  : LONGCARD(8)  --> Länge
  235.        8  : UBYTE(Depth) --> Anzahl Planes in Quell-Grafik
  236.        9  : UBYTE        --> Füllbyte, 0.
  237.        10 : CARDINAL(PlanePick)  --> siehe Intuition Ref. Manual, S.192 ff
  238.        12 : CARDINAL(PlaneOnOff)
  239.        14 : CARDINAL(PlaneMaks)  --> zum schreiben benutzte Bitplanes.
  240.  
  241.     "CAMG", gibt besondere ViewModes an:
  242.  
  243.        0  : "CAMG"
  244.        4  : LONGCARD(4)
  245.        8  : LONGSET(ViewMode) --> Entspricht nicht (!) ViewModeSet{}.
  246.                  { 2} : Interlace
  247.                  {10} : BoublePlayField
  248.                  {17} : Hold and Modify
  249.                  {31} : hires
  250.  
  251.     "CRNG", für Colorcycling:
  252.  
  253.        0  : "CRNG"
  254.        4  : LONGCARD(8)
  255.        8  : INTEGER       --> 0, nicht benutzt.
  256.        10 : INTEGER(rate) --> Geschwindigkeit 60 je sec = 8000H
  257.                           -->   30 je sec: 4000H, 1 pro sec: 8000H DIV 60...
  258.        12 : INTEGER       --> eingeschaltet: ungleich 0
  259.        14 : UBYTE(low)    --> unterste und
  260.        15 : UBYTE(high)   --> oberste Grenze der Farbe.
  261.  
  262.     "BODY", enthält die eigenlichen Bilddaten:
  263.  
  264.        0  : "BODY"
  265.        4  : LONGCARD(x)  --> Länge (Höhe*Breite*Tiefe/8)
  266.        8  : Daten.    Je nachdem, ob in "BMHD" Compressed gewählt
  267.                       wurde, gepackt oder nicht.
  268.  
  269.        ungepackte BitMapDaten:
  270.  
  271.            Daten der Reihe nach gespeichert: Zuerst 1. Zeile 1.
  272.            Bitplane, dann 1. Zeile 2. Bitplane etc. Danach 2. Zeile 1.
  273.            Bitplane, 2. Zeile 2. Bitplane etc.
  274.  
  275.        gepackte BitMapDaten:
  276.  
  277.            gepackt wird nur innerhalb einer Zeile. Die Zeilen sind der
  278.            Reihe nach wie bei ungepackt gespeichert.
  279.            Gepackt wird Byteweise:
  280.            Ist ein Byte
  281.            0..127  : bedeutet das: Die nächsten n+1 (1..128) Bytes
  282.                      unverändert in die Grafik laden.
  283.            129..255: Das folgende Byte wird 257-n mal hintereinanger in die
  284.                      Grafik kopiert.
  285.            128     : keine Funktion.
  286.  
  287.     weitere Datenblocks:
  288.       "SPRT"    für Sprites
  289.       "CCRT"    Graphiccraft: Colorcycling
  290.       "CMHD"    Graphiccraft (???)
  291.       "DPPV"    Graphiccraft (???)
  292.  
  293.       ein Ladeprogramm sollte Daten, die unbekannte Kennungen haben,
  294.       einfach überlesen. Die Länge steht ja jeweils im folgenden
  295.       Langwort.
  296.  
  297.   Ein ILBM-File muß die Blocks "BMHD" und "BODY" enthalten. "CMAP"
  298.   sollte vorhanden sein. Alle anderen sind optional.
  299.  
  300. Beispiel:
  301.   0000: 464F524D 0000567A 494C424D 424D4844    FORM..VzILBMBMHD
  302.   0010: 00000014 014000C8 00000000 05020100    .....@..........
  303.   0020: 00020A0B 014000C8 434D4150 00000060    .....@..CMAP...`
  304.   0030: 00000090 10000000 00200020 30003040    ......... . 0.0@
  305.   0040: 10305010 40602050 70305080 4060A050    .0P.@` Pp0P.@`.P
  306.   0050: 70B06070 C07080D0 9090E0A0 A0F0C0C0    p.`p.p..........
  307.   0060: F06020D0 5020B040 10903010 60301040    .` .P .@..0.`0.@
  308.   0070: 20103000 000000B0 0000A000 00A00000     .0.............
  309.   0080: A00000A0 0000A000 00A00000 A00000A0    ................
  310.   0090: 44505056 00000068 00000000 00000000    DPPV...h........
  311.   00A0: 01680000 014000C8 0002005A 00020000    .h...@.....Z....
  312.   00B0: 00020000 00020000 00000000 00000000    ................
  313.   00C0: 00000000 00000000 00000000 00000000    ................
  314.   00D0: 00000000 00000000 00000000 00010002    ................
  315.   00E0: 00000000 00000000 00000000 00010002    ................
  316.   00F0: 00000000 00000000 00000000 00010002    ................
  317.   0100: 43524E47 00000008 19961800 0002020F    CRNG............
  318.   0110: 43524E47 00000008 29304E78 00039D26    CRNG....)0Nx...&
  319.   0120: 43524E47 00000008 DD41AB4A FFFFFFF7    CRNG.....A.J....
  320.   0130: 43524E47 00000008 0047FFF4 00000001    CRNG.....G......
  321.   0140: 424F4459 00005539 11043336 01EFDC3F    BODY..U9..36...?
  322.   0150: DCC00000 0161000D FFFF40F9 00026130    .....a....@...a0
  323.   0160: 03FE0004 B5C0C890 E1FE0011 FDC337FF    ..............7.
  324.  
  325.   Dies ist ein Beispiel für eine Lores-Grafik mit der Auflösung 320
  326.   mal 200 (14H: 0140H; 16H: 0C8H). Die Tiefe beträgt 5 Bitplanes
  327.   (1CH), deshalb besteht sie aus 32 Farben (in 2CH steht 60H, durch 3
  328.   also 20H=32). Die Daten in DPPV sollten überlesen werden. Die 4 CRNG
  329.   Blöcke sind meist auch unwichtig.
  330.  
  331. -- Fridtjof.
  332.